Skip to main content

2장. 로컬 코딩 워크플로의 구성 요소

2.1 모델: 코드를 이해하고 생성하는 두뇌​

로컬 코딩 워크플로의 첫 번째 구성 요소는 모델입니다. 모델은 코드를 읽고, 설명하고, 생성하는 두뇌 역할을 합니다. 그러나 사람의 두뇌처럼 프로젝트 전체를 기억하고 판단하는 것은 아닙니다. 모델은 입력으로 받은 토큰을 바탕으로 다음 토큰을 예측합니다. 따라서 모델 품질과 함께 입력 품질이 매우 중요합니다.

좋은 코딩 모델은 몇 가지 특징을 보입니다. 코드 문법을 잘 지킵니다. 함수와 클래스의 역할을 파악합니다. 테스트 코드 형식을 이해합니다. 에러 메시지를 보고 원인을 추정합니다. 기존 코드 스타일을 어느 정도 따라갑니다. 반대로 나쁜 코딩 모델은 존재하지 않는 API를 지어내거나, 프로젝트에 없는 패키지를 사용하거나, 함수 시그니처를 마음대로 바꿀 수 있습니다. 할루시네이션은 여기서도 나옵니다.

모델을 고를 때는 이름보다 역할을 먼저 정해야 합니다. 자동완성용 모델은 빠른 응답이 중요합니다. 채팅용 모델은 설명력과 코드 이해력이 중요합니다. 리팩터링용 모델은 지시를 잘 따르고 변경 범위를 지키는 능력이 중요합니다. 에이전트용 모델은 파일을 읽고 단계적으로 작업하는 능력이 중요합니다. 같은 모델 하나로 모든 역할을 맡길 수도 있지만, 쾌적한 실무 환경에서는 역할에 따라 모델을 나누는 편이 좋습니다.

2.2 런타임: 모델을 실행하는 엔진​

모델 파일만 있다고 AI가 동작하지는 않습니다. 모델을 메모리에 올리고, 토큰을 계산하고, 응답을 생성하는 실행 엔진이 필요합니다. 이것이 런타임입니다. llama.cpp, MLX, vLLM, Ollama 내부 엔진, LM Studio의 런타임 등이 이 영역에 속합니다.

런타임은 하드웨어와 밀접합니다. NVIDIA GPU를 잘 활용하려면 CUDA 계열 가속이 중요합니다. Apple Silicon에서는 Metal이나 MLX 기반 실행이 중요합니다. CPU만으로 실행할 때는 AVX2 같은 CPU 명령어 지원이 영향을 줄 수 있습니다. LM Studio의 시스템 요구사항에서도 Windows x64 환경에서 AVX2 지원을 요구하고, macOS에서는 Apple Silicon과 macOS 14 이상을 기준으로 안내합니다.

초보자는 처음부터 런타임을 깊게 파고들 필요는 없습니다. 다만 문제가 생겼을 때 “모델이 나쁜가”와 “실행 엔진이나 하드웨어 설정이 맞지 않는가”를 구분할 수 있어야 합니다. 같은 모델도 런타임과 설정에 따라 속도와 안정성이 달라집니다.

2.3 로컬 서버: IDE와 모델을 연결하는 통로​

로컬 서버는 IDE와 모델 사이의 통로입니다. LM Studio에서 서버를 켜면 내 컴퓨터 안에 API 서버가 열립니다. Continue는 이 서버 주소로 요청을 보냅니다. 사용자는 IDE 안에서 질문하지만, 실제로는 IDE 확장이 HTTP 요청을 만들고, 로컬 서버가 그 요청을 받아 모델에게 전달합니다.

여기서 localhost는 내 컴퓨터 자신을 의미합니다. 1234는 포트 번호입니다. /v1은 API 경로의 기본 버전처럼 쓰입니다. 그래서 http://localhost:1234/v1이라는 주소는 “내 컴퓨터의 1234번 포트에서 동작하는 v1 API”라는 뜻입니다. LM Studio 공식 문서는 OpenAI 클라이언트의 base URL을 LM Studio 서버 주소로 바꾸는 방식으로 OpenAI 호환 API를 사용할 수 있다고 설명합니다.

로컬 서버 개념을 이해하면 연결 문제를 해결하기 쉬워집니다. Continue가 응답하지 않을 때는 먼저 LM Studio 서버가 켜져 있는지 봅니다. 그다음 포트가 맞는지 봅니다. 그다음 모델 ID가 맞는지 봅니다. 마지막으로 방화벽이나 네트워크 설정을 봅니다. 대부분의 초반 오류는 이 네 단계 안에서 해결됩니다.

[이미지 제안 2-1] VS Code와 LM Studio 연결 흐름. VS Code Continue 확장 → http://localhost:1234/v1 → LM Studio 서버 → 로컬 모델 순서로 표시합니다.

2.4 IDE 확장: VS Code, Continue, Copilot​

IDE 확장은 개발자가 AI를 실제로 만나는 접점입니다. 모델이 아무리 좋아도 개발자가 매번 앱을 오가며 코드를 복사해 붙여 넣어야 한다면 작업 흐름이 깨집니다. IDE 확장은 현재 파일, 선택한 코드, 열려 있는 탭, 터미널 출력, Git diff 같은 정보를 모델에게 전달하기 쉽게 만들어 줍니다.

VS Code는 확장 생태계가 넓기 때문에 AI 코딩 도구를 실험하기 좋습니다. Continue는 오픈소스 AI 코드 에이전트로, 채팅, 편집, 자동완성 같은 기능을 제공합니다. Part 4에서는 Continue를 사용해 LM Studio의 로컬 모델을 VS Code에서 쓰는 흐름을 다룹니다.

Copilot은 GitHub와 Microsoft 생태계의 대표적인 AI 코딩 도구입니다. Part 5에서 더 자세히 다루겠지만, 여기서는 역할만 이해하면 됩니다. Copilot은 클라우드 기반 경험이 강하고, Continue는 다양한 모델 공급자와 로컬 모델 연결에 유연합니다. 두 도구는 경쟁 관계이기도 하지만, 실무에서는 역할을 나누어 함께 쓸 수도 있습니다.

2.5 에이전트: 파일을 읽고, 수정하고, 명령을 실행하는 작업자​

채팅 모델은 질문에 답합니다. 에이전트는 한 걸음 더 나아가 작업을 수행합니다. 예를 들어 “이 버그를 고쳐 주세요”라고 했을 때, 에이전트는 관련 파일을 찾고, 코드를 읽고, 수정안을 만들고, 테스트를 실행하고, 실패하면 다시 고칠 수 있습니다. 물론 이 모든 과정이 항상 정확한 것은 아닙니다. 그래서 에이전트는 강력하지만 조심해서 써야 합니다. 반드시 내가(사람이) 과정을 확인하고, 어디에서 문제가 생기는지, 하면 되는 것과 하면 안되는 것을 꼼꼼히 챙겨야 합니다.

에이전트의 핵심은 도구 사용(툴 콜링)입니다. 파일 읽기, 파일 쓰기, 검색, 터미널 명령 실행, 테스트 실행 같은 도구를 모델이 호출할 수 있습니다. 이때 위험도도 커집니다. 잘못된 파일을 수정할 수 있고, 명령어가 부작용을 만들 수 있고, 보안상 민감한 파일을 읽을 수 있습니다. 그래서 에이전트 워크플로에는 Git 브랜치, 변경 사항 리뷰, 테스트 실행, 권한 제한이 반드시 필요합니다.

Part 4에서는 Continue를 통한 IDE 기반 보조에 집중합니다. Part 6에서는 터미널 기반 에이전트를 더 깊게 다룹니다.

다시 말씀드리지만, 에이전트에게는 큰 목표를 한 번에 맡기기보다 작은 작업을 순서대로 맡기는 것이 좋습니다.

2.6 터미널 기반 코딩 에이전트의 장점​

터미널 기반 코딩 에이전트는 IDE 확장보다 더 직접적으로 프로젝트 폴더와 상호작용합니다. 명령어를 실행하고, 테스트 결과를 보고, 파일을 수정하는 흐름이 자연스럽습니다. 스크립트, 테스트 명령, 린트 명령, 빌드 명령이 이미 터미널 중심으로 되어 있는 팀이라면 터미널 에이전트가 잘 맞습니다.

장점은 자동화입니다. IDE 안에서 사람이 코드를 선택하고 요청하는 방식은 직관적이지만, 반복 작업을 표준화하기에는 한계가 있습니다. 터미널 에이전트는 “테스트 실행 → 실패 원인 요약 → 수정안 생성 → 다시 테스트” 같은 루프를 만들기 쉽습니다. 또한 서버나 원격 개발 환경에서도 사용하기 좋습니다.

단점은 안전성입니다. 터미널 명령은 파일 시스템과 개발 환경에 직접 영향을 줍니다. 따라서 처음부터 rm, git push, 데이터베이스 마이그레이션 같은 위험한 명령을 자유롭게 실행하게 두면 안 됩니다. 에이전트는 개발자의 손을 빠르게 해 주지만, 브레이크가 없는 도구가 되어서는 안 됩니다.

2.7 “로컬 자동완성”과 “로컬 에이전틱 코딩”의 차이​

로컬 자동완성과 로컬 에이전틱 코딩은 같은 로컬 AI 범주에 있지만 성격이 다릅니다. 자동완성은 개발자가 입력하는 도중에 다음 코드를 제안합니다. 빠른 속도와 낮은 지연 시간이 중요합니다. 모델은 대개 현재 파일과 주변 코드만 보고 짧은 제안을 합니다.

에이전틱 코딩은 작업 단위가 큽니다. 모델이 파일을 찾고, 여러 파일을 읽고, 수정하고, 테스트를 실행합니다. 속도도 중요하지만, 더 중요한 것은 계획, 컨텍스트 선택, 변경 범위 통제입니다. 에이전트는 긴 작업을 수행하므로 모델의 추론 능력과 도구 사용 안정성이 중요합니다.

따라서 같은 모델을 쓰더라도 설정이 달라질 수 있습니다. 자동완성은 작은 모델, 낮은 지연 시간, 짧은 출력이 좋습니다. 에이전틱 코딩은 더 큰 모델, 긴 컨텍스트, 낮은 temperature, 명확한 지시가 좋습니다. 이 차이를 모르고 하나의 모델에 모든 작업을 맡기면 “자동완성은 느리고, 에이전트는 멍청하다”는 느낌을 받을 수 있습니다. 역할에 맞게 모델과 설정을 나누면 체감이 훨씬 좋아집니다.

[표 2-2] 로컬 자동완성과 로컬 에이전틱 코딩 비교.